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REMARKS 



Claims 1-4 and 7-13 are pending in the present application. Claims 1-4 and 7-11 
were rejected, and Claims 5 and 6 were withdrawn from consideration, in an Office 
Action dated 1 1/05/2003. Claims 1 , 4, 8 and 10 have been amended, claims 5 and 6 have 
been cancelled, and Claims 12 and 13 have been added, herewith. Reconsideration of the 
claims is respectfully requested. 

Amendments were made to the specification to correct errors and to clarify the 
specification. No new matter has been added by any of the amendments to the 
specification. 

I. Restriction 

Applicants affirm the election of Invention I, Claims 1-4 and 7-11. 

IL Specification 

Applicants have amended the Specification in an attempt to address the 
Examiner's comments/concerns regarding use of trademarks. 

IH. 35 U.S»C, S 102. Anticipation 

A. The Examiner rejected Claims 8 and 1 1 under 35 U.S.C § 102 as being 
anticipated by Beauchamp et al (6,621 ,505). This rejection is respectfully traversed. 

With respect to Claim 8 r such claim has been amended to recited that the 
information received from the ERP interface is converted into a strongly typed object 
form. Applicants show that none of the cited references teach or suggest the claimed 
feature of "an ERP web gateway in communication with said web server for converting 
said requests from said web server into language format required by an interface of said 
ERP application and to convert information received from said interface of said ERP into 
a strongly typed object form". As can be seen, Claim 8 recites an ERP web gateway that 
perfoims two types of conversions - converting requests from a web server into language 
format required by au ERP application interface, and convert information received from 
such interface into a strongly typed object fbnn. The cited reference merely teaches an 
BO (business office) gateway that provides a communication path between a process 
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server and the back-end enterprise system (Beauchamp Col. 19, lines 64-67). The 
business objects maybe capable of accessing data and fiinctionahty (Beauchamp Col. 20, 
lines 6-8). There is no teaching of any type data conversion by a gateway, as claimed. 
Thus, amended Claim 8 is shown to not be anticipated by the cited reference. 

B. The Examiner rejected Claim 7 under 35 U.S.C. § 1 02 as being anticipated by the 
J2EE L2 specification and accompanying reference applications published December 17, 
1999. This rejection is respectfully traversed. 

Applicants show that the cited reference does not teach the cl aimed feature of "A 
method of presenting strongly typed Java objects using HTML by merging Java objects 
with XML template files" (emphasis added by Applicants), In rejecting Claim 7, the 
Examiner states that the cited J2EE reference teaches this at pages 3-4, 5-5, 5-9, 5-10, 
and 5-14. Applicants have thoroughly reviewed these pages, and do not see any teaching 
or other mention of any type of merging operation, including merging of Java objects 
with XML template files to present strongly typed Java objects using HTML, as claimed. 
If the Examiner maintains this rejection, further clarification is requested as to where 
such merging is taught. 

C Applicants traverse the rejection of Claim 1 1 for similar reasons to those given 
above regarding Claims 7 and 8. 

D. Therefore, the rejection of Claims 7, 8 and 1 1 under 35 U.S.C. § 102 has been 
overcome. 

IV. 35 U.S.C. 8 103. Obviousness 

The Examiner rejected Claims 1-4, 9 and 10 under 35 U.S.C. § 103 as being 
unpatentable over the J2EE specification in view of Beauchamp et al. This rejection is 
respectfully traversed. 

Applicants show that the cited references have been improperly combined using 
hindsight, and even when improperly combined there are still missing claimed elements - 
strongly evidencing non-obviousness. In combining the references, the Examiner states: 
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"it would have been obvious to a person, of ordinary skill ux the art to use 
the method disclosed by the J2EE specification to implement the system 
described by Beachamp as tins would bring the benefit of the wealth of 
design and deployment tools available for applications that use the J2EE 
specification." 

Applicants show that this general statement - which essentially states that it would have 
brought a tool benefit - is not a sufficient showing of a motivation to combine these 
references, "[wjhen determining the patentability of a claimed invention which combines 
two known elements, 'the question is whether there is something in the prior art as a 
whole to suggest the desirability, and thus the obviousness, of making the combination.'" 
See In reBeattie, 974 F.2d 1309, 1311-12, 24 USPQ2d 1040, 1042 (Fed. Or. 1992) 
(quoting Lindemann Maschinenfabrik GmbH v. American Hoist & Derrick Co,, 730 F.2d 
1452, 1462,221 USPQ 481, 488 (Fed. Cir. 1984)). There is certainly nothing in the cited 
art that suggests the desirability of making such combination. In fact, there is something 
in the cited art that would suggest a non-desire to make the combination. The 
Beauchamp reference provides for supporting legacy ERP applications. However, the 
cited J2EE reference expressly states its tools do not enable support for such legacy ERP 
applications (J2EE page 2-2, last sentence), and that such support will not be available 
until some undefined future release. This strongly evidences no motivation to combine 
the references as the J2EE teachings do not operate to support legacy ERP applications as 
taught by Beauchamp. The only motivation to combine the references comes from 
Applicants' own patent specification, which is improper hindsight analysis. It is error to 
reconstruct the patentee's claimed invention from the prior art by using the patentee's 
claims as a "blueprint". When prior art references require selective combination to 
render obvious a subsequent invention, there must be some reason for the combination 
other than the hindsight obtained from the invention itself Interconnect Planning Corp. 
v. Feit, 11 A F.2d 1 132, 227 USPQ 543 (Fed. Cir. 1985). There is simply no reason to 
combine the references other than the hindsight obtained by the present invention. 
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Applicants will now show that even when the references have been improperly 
combined, there are still missing claimed elements - strongly evidencing non- 
obviousness. 

With respect to Claim 1, Applicants show that none of the cited references teach 
or suggest the claimed feature of "merging said output data from said ERP application 
into a strongly typed Java object". Iti rejecting Claim 1, the Examiner states that this is 
taught by the J2EE specification on page 2-4. Applicants show that there, the J2EE 
specification states: 

'T>atabase: The J2EE platform includes a database, accessible through 
the JDBC API, for the storage of business data. The database is accessible 
from web components, enterprise beans, and application client 
components. The database need not be accessible from applets." 

As can be seen, while this cited J2EE passage does mention the existence of a database 
for storage of business data, it merely states that the database is "accessible". It does not 
teach or suggest any type of merging operation, including merging said output data from 
said ERP application into a strongly typed Java object In addition, the J2EE 
specification expressly acknowledges that it does not yet support ERP applications. On 
page 2-2, it states: 

"A future release of this specification will describe standard ways to 
extend J2EE services with connectors to other non-J2EE application 
systems, such as mainframe and ERP systems." 

Thus, it is not a reasonable interpretation of the J2EE specification to state that it teaches 
the claimed step of ''merging said output data from said ERP application into a strongly 
typed Java object" as the reference does not teach such a merging step and also doesn't 
support ERP applications. Claim 1 is thus shown to not be obvious as there is at least one 
claimed element not taught or suggested by any of the cited references that are being used 
in rejecting such claim. 
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In similar fashion, as there is no teaching or suggestion of merging ERP 
application output data into a strongly typed Java object, there is no teaching or 
suggestion of transforming such strongly typed Java object into a transmittable format 
(since a Java object never existed, and thus there is nothing to transform). Claim 1 is thus 
further shown to have missing claimed elements not taught or suggested by the cited 
reference. 

Further with respect to Claim 1, Applicants show that none of the cited references 
teach or suggest the claimed feature of ''transferring any data entered by said user into 
said HTML input form and any data stored in said requested HTML page into said ERP 
application API". As can be seen, this claimed step is directed to transfer of two sources 
of data to the ERP application API. The Examiner states that Beauchamp Figure 7 
teaches transferring data from said request into an ERP application. Applicants show that 
while Figure 7 shows a path between process server 202 and ERP system 204, it certainly 
does not teach or suggest that data flowing to the ERP system contains any data entered 
by a user, and any data stored in a requested HTML page. Therefore, Claim 1 is further 
shown to have been erroneously rejected under 35 U.S.C. 103. 

With respect to Claim 2, Applicants initially traverse for reasons given above 
regarding Claim I (of which Claim 2 depends upon). Further with respect to Claim 2, 
Applicants show that none of the cited references teach or suggest the claimed feature of 
"wherein, said merging step comprises the step of merging said output data from said ERP 
application into a strongly typed object form using an ERP Web Gateway, wherein said 
strongly typed object form comprises strongly typed Java objects". In rejected Claim 2, 
the Examiner states that Beauchamp discloses merging data from an ERP application 
using an ERP Web Gateway in Figure 7, Applicants show two-fold error in this 
assertion. First, Applicants are not merely recited '*merging of data", but rather are 
specifically reciting that the data (from the ERP application) is merged into a strongly 
typed object. Beauchamp's Figure 7 does not teach or suggest such merger into a 
strongly typed object. Secondly, the claim recites that this merging is done using an ERP 
Web Gateway. The gateway shown by Beauchamp's Figure 7 is described at Beauchamp 
CoL 19, lines 64-67, where it states "The process server 202 communicates with the 
back-end enterprise systems 204 using business objects (BO) 216 through a business 
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object gateway 218." The cited gateway merely provides a communication path and does 
not provide any type of merging operation, as claimed. Thus, Claim 2 is further shown to 
not be obvious in vi ew of the cited references as there are missing claimed elements not 
taught or suggested by the cited references. 

Applicants initially traverse the rejection of Claim 3 for similar reasons to those 
given above regarding Claim 1 (of which Claim 3 depends upon). Applicants further 
traverse the rejection of Claim 3 by showing that none of the cited references teach or 
suggest the claimed feature of "wherein said HTML input form, dynamic ERP 
Application data access, Java objects definitions and HTML report form are stored in 
form of XML files". In rejecting Claim 3, the Examiner states that this is taught by the 
cited J2EE specification (e.g. 8-9). Applicants show that to the contrary, Claim 3 recites 
that all of the listed items are stored in form of XML files. The cited reference does not 
teach storing of all these items in XML files. For example, dynamic ERP Application 
data access is not taught or suggested by the cited reference in any fashion, so it can't be 
reasonably stated that such is stored in an XML file. The passage cited by the Examiner 
merely describes XML grammar for a J2EE application deployment descriptor, but does 
not teach or otherwise suggest storing of the listed items of Claim 3 in an XML file. 
Thus, Claim 3 is further shown to not be obvious in view of the cited references. 

Applicants initially traverse the rejection of Claim 4 for similar reasons to those 
given above regarding Claim 1 (of which Claim 4 depends upon). Applicants further 
traverse the rejection of Claim 4 by showing that none of the cited references teach or 
suggest the claimed feature of "wherein said XML file strongly couples said data in said 
ERP Application to said Java objects and said XML file which specifies the presentation 
of said Application data'*. As can be seen, Claim 4 states that the XML file specifies 
presentation of the ERP Application data. In rejecting Claim. 4, the Examiner states that 
this is taught by the cited J2EE specification. Contrary to this assertion, Applicants show 
that the J2EE specification explicitly states that it does not provide support for ERP 
applications (as discussed above regarding Claim 1), so it is not seen how this 
specification teaches or suggests an XMP file that specifies presentation of ERP 
Application data. Thus, Claim 4 is further shown to not be obvious in view of the cited 
references. 
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Applicants traverse the rejection of Claim 9 for similar reasons to those given 
above regarding Claim 1 (of which Claim 9 depends upon). 

Applicants traverse the rejection of Claim 10 for similar reasons to those given 
above regarding Claim 4 (of which Claim 10 depends upon). 

Therefore, the rejection of Claims 1-4, 9 and 10 under 35 U.S.C § 103 has been 
overcome. 

V* Newly Added Claims 

Claims 12 and 13 have been added herewith, and examination of such claims is 
respectfully requested. 

VI. Conclusion 

It is respectfully urged that the subject application is patentable over the cited 
references and is now in condition for allowance. The Examiner is invited to call the 
undersigned at the below-listed telephone number if in the opinion of the Examiner such 
a telephone conference would expedite or aid the prosecution and examination of this 
application. 



DATE: 0. / <V <3 f 



Respectfully submitted, 




Duke W. Ycc 
Reg. No. 34,285 



Wayne P. Bailey 
Reg. No. 34,289 



Carstens, Yee & Cahoot), LLP 



P.O. Box 802334 
Dallas, TX 75380 
(972) 367-2001 



Attorneys for Applicants 
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